Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_0799/734

Internet Message Format | 1994-08-27 | 6.9 KB

From: [e-mail] (Mark Baker)
Date: 08 Jul 94  17:44:24
Message-Id: <UUCP.773720818@mettav>
Subject: Digest
To: [e-mail] ([e-mail])
Precedence: bulk

Evan:
 > If the group decided that we need multi-purpose keys, and the use of
 > shift is implicit, then why can't the use of shift be implicit in alpha
 > keys too?    So ^A is shift-control-A and ^a is just control-A?  This
 > makes the idea of an implicit shift global throughout all key definitions
 > making the non-alpha implicit keys more understandable (you will know a
 > app uses implicit shift in the keys as soon as you see lower-case letters
 > in the menus).   This also saved a symbol in the menus.

I think we should avoid multi-purpose keys as much as possible, but if we need
them then yes you can't specify shifted and unshifted as different, it has to
be done implicitly. But for letters you mustn't do it implicitly:
capslock-ctrl-A should be the same as ctrl-A not shift-ctrl-A. Which is not
what your system would suggest. Also bear in mind that all existing software
has ^Q on the menu for unshifted ctrl-Q and your proposal would cause
confusion.

 > I think I'm making a pretty strong argument here for the use of implicit
 > shift throughout the key definitions and have shown that we MUST use
 > implicit shift if we use multi-purpose keys at all.

Yes, the multipurpose keys need implicit shift, but you can't use it for
letters.

 > Now look deeper into the problem.  Say, 50% or programmers support the
 > App-defs file and 50% of the apps only use the level #1 standard.  A user
 > could then have most of his apps configurable, and he can change those
 > keys, but if he changes from the defaults, the other half of his
 > applications will not use the same keyboard short-cuts!!  This is not _A_
 > standard as it creates TWO incompatible standards.  The only way the

Yes. The app-defs file must be either abandoned or made compulsory. I'm
inclined to agree with you but the problem with this is that lazy programmers
will ignore it and just stick with the Atari standard shortcuts, with the same
problems as if both standards were allowed.

 > beyond the scope of the GEM-List.  The GEM-List only supplements ATARI's
 > documentation.

And replaces part of it. But yes it should be read in conjunction with Atari's.

 > If you have AES 3.4 or greater, you should check and see what features
 > are present in the system using appl_getinfo().

Isn't this only in aes >= 4.00? Or is this another bug in the Compendium?

 > o  Prior to drawing a dialog and calling form_do(), call wind_update
 > (BEG_UPDATE).  Do not call wind_update (END_UPDATE) until the dialog is
 > removed and user-interaction is complete.

Necessary for MultiTOS. Lattice C documentation didn't include this which is
why a lot of old programs failed under MultiTOS.

 > Use these guidelines to construct your own form_do().  It should emulate
 > form_do() EXACTLY!  I recommend that you use form_do() and not write
 > your own handler for the majority of user interaction, allowing a custom
 > global form_do() replacement to be used to keep interfaces consistent.

Except that apps should be non-modal now IMO. But those that are modal should
use form_do I agree.

 > o  Fully non-modal dialogs are difficult on both the programmer and the
 > user.  Some possibilities would be a font-selection dialog, where the
 > user could change fonts with the dialog and edit the document at the same
 > time. In these cases, OK doesn't have to end the dialog, just make the
 > proper change in the document, and the closer removes the dialog.

OK should close the dialogue. To make changes and leave the dialogue open Apply
should be used. To cancel changes and leave the dialogue open, Revert should be
used.

 > The right mouse button should be used as follows when clicked on :
...

Thanks for posting this, it was interesting. BTW, you mention three button
mice, I knew GEM supported three (and up to 8 :) button mice but I had never
heard of anyone fitting one. What should a program do with middle button
clicks?

Rainer:
 > For shortcuts with single purpose keys (A-Z,DEL,HELP,DEL,...) we always
 > use uppercase; 'Shift-(Cntrl)- A' is 'UParrow-(^)-A' and 'Cntrl-A' is '^A'
 > as on the keys the letters are always uppercase.
 > So if you want to press 'A' you are pressing the key 'A' (and not 'a')
 > and for 'Shift-A' the shift-key + the key 'A' as 'UParrow-A' shows.
 >
 > For all other shortcuts with non-single purpose keys (%&>...) we use no UP-
 > arrow. The user just has to press the combination (with or without shift)
 > that the national keyboard need.

Yes that is what I had assumed would be used.

 > Characters that need more than the shift key have to be excluded or the
 > Cntrl-Alt-Shift combination that is needed shouldn't be allowed.

Which characters are they?

Bo:
 > global (editable) SYS file, which could be varied for different language
 > groups (say all US developers want to use ^W instead of ^U: they modify
 > their SYS file and German programs supporting this will show ^W, and
 > Germans using US programs will find ^U in their menus).

Yes, this is the best argument for the app_defs.sys file - it stops people
arguing whether to use Profibuch or Atari shortcuts ;)

 >> chars on a normal UK keyboard are \,./;'#[]-=` The only ones on both
 >> these lists are ',.- which is fairly restrictive.
 >
 > Exactly. So they should be avoided.

They should be avoided as much as possible. They can be used if you don't
specify whether to use shift; specify the character and the user presses shift
if necessary on their keyboard.

All this is solved by using the app_defs.sys file, apart from application
specific shortcuts.

 > Anyway, I agree with a previous poster saying that choice of block
 > handling should be left to the application (since GEM doesn't impose global

Better still, left to the user :)

Timothy:
 > )  o  Avoid using the word "error" or any term which may blame the user.
 >
 > )  o  Use 'Cannot' instead of "Can not' or 'Can't"
 >
 > To these, I laugh.  Why did Atari specify these?  I suppose you'd want to
 > avoid pissing off the user, but some times errors really do occur, and
 > some times, things are REALLY the user's fault.  And what is so important

And when they aren't the users fault it can still be an error anyway. `Fatal
disc <small problem absolutely not your fault...>'

 > about the word 'cannot' that they have to put this in a guideline?  It
 > just seems silly to say not to use "can not" or "can't".

Can not is actually incorrect. It suggests you have the option of not doing it
if you like :) Cannot is correct English, but why can't isn't allowed I don't
know.

Annius:
 > What would be the advantage of a standard?  That people can exchange
 > their resource files?  Why would they want to do that?

It's for use with things like libraries - if a library registers which extended
types it supports then programmers can switch libraries easily, and it allows
the use of aes extensions.